Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9610/000043_owner-urn-ietf _Tue Oct 15 12:41:27 1996.msg

Internet Message Format | 1997-02-19 | 5KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA00547 for urn-ietf-out; Tue, 15 Oct 1996 12:41:27 -0400
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA00542 for <[e-mail]>; Tue, 15 Oct 1996 12:41:23 -0400
Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA05733  (mail destined for [e-mail]); Tue, 15 Oct 96 12:41:19 -0400
Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id KAA21184; Tue, 15 Oct 1996 10:40:52 -0600 (MDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 15 Oct 1996 10:48:22 -0600
To: Larry Masinter <[e-mail]>, [e-mail]
From: Ron Daniel <[e-mail]>
Subject: Re: [URN] a possible security architecture for URNs
Sender: [e-mail]
Precedence: bulk
Reply-To: Ron Daniel <[e-mail]>
Errors-To: [e-mail]

Thus spoke Larry Masinter (at least at 01:01 AM 10/15/96 PDT)
>Check out
>Rivest & Lampson, "A Simple Distributed Security Infrastructure"
>    http://theory.lcs.mit.edu/~rivest/sdsi10.html

Thanks for the citation. The paper is interesting. Unfortunately,
we (the URN-WG) are not competent to judge the merits of this
proposal relative to the SPKI work already going on in the IETF.

Larry has raised the issue of security in a few different places:
first he said that the lack of security and administration tools
in DNS made NAPTRs unacceptable, later he made a similar criticism
of the framework.

However, the URN requirements draft does not mandate that any particular
level of security must be provided. That RFC says:
  "...there are several issues dealing with support for
   replication of resources and security that have been
   discussed; however, the problems are not well enough
   understood at this time to include specific requirements
   in those areas here."
I am unaware of any changes to that status.


Security has its costs. While it would be nice to have URN resolution
systems that met a requirements statement like:
   URN resolution systems shall be invulnerable to forged responses,
   shall ensure that only authorized accesses are possible, shall
   provide for the complete confidentiality of the resource, and
   shall be immune to traffic analysis and denial of service attacks"
who is going to pay for such high levels of security? Such measures are
not appropriate for all the resources people will identify with URNs.

My contention is that such objections should not slow the NAPTR
draft from going to experimental status. Here are my reasons:
  1) As shown above, the URN requirements RFC has no requirement
     for security. This was not an oversight, it was because we were
     not ready to impose security requirements on all URN systems.
  2) Experimental RFCs are not standards-track documents. The goal
     is to gain experience with a new protocol with the explicit
     understanding that it is an experiment and may never go to the
     standards track.
     We actually have some useful things to learn from NAPTRs.
     URNs are supposed to be long-lived, location-independent identifiers.
     The NAPTR draft gives us a way to look at location independence
     in action. Michael has mentioned on this list that he is working
     on an rwhois-based alternative to NAPTRs. He has stated to me
     that he would like to see NAPTRs deployed and running so that he
     can learn from that system while he continues to develop his.
     Experimental status seems perfectly appropriate for this purpose.
  3) While it is easy to ask for security, it is hard to deploy. The DNSSEC
     work is actually rather far along. The main impediment to further
     progress appears to be the difficulty in fielding implementations.
     This difficulty is due to export control issues surrounding the
     crypto code, and is a difficulty that *any* resolution system
     with strong security would face.

Allowing the NAPTR draft to procede as an Experimental RFC will let us
get the operational experiance with resource replication that the URN
Requirements RFC says we need. The possibility also exists that the
export control problems associated with DNSSEC will be overcome during
the experimental period. We can then experiment with the SIG resource
record and gain experience with the security issues that the requirents
document says we need.

Regards,
Ron Daniel Jr.                       email: [e-mail]
Advanced Computing Lab               voice: [phone]
MS B287                                fax: [phone]
Los Alamos National Laboratory        http://www.acl.lanl.gov/~rdaniel/
Los Alamos, NM, USA  87545    obscure_term: "hyponym"